Systems and methods for a realtime creation and modification of a dynamic media player and a disabled user compliant video player

ABSTRACT

Methods and systems for a disabled user compliant video player for an end-to-end streaming web video solution affording accessibility for disabled users, including blind users and those with partial or poor vision, colorblind users, deaf users and those limited to only keyboard/voice input. Another embodiment of the present invention is directed to systems and methods for real-time creation and modification of specialized media players, to be used as stand-alone applications or as embedded data display applications.

PRIORITY CLAIM

This application claims priority to U.S. Provisional Patent ApplicationSer. No. 61/054,794 filed May 20, 2008, U.S. Provisional PatentApplication Ser. No. 61/055,058 filed May 21, 2008 and U.S. ProvisionalPatent Application Ser. No. 61/090,192 filed Aug. 19, 2008. All of theforegoing applications are hereby incorporated by reference in theirentirety as if fully set forth herein.

GOVERNMENT RIGHTS

Portions of one or more embodiments of the invention(s) described hereinwere made with Government support under contract GSV06PD00165 awarded bythe General Services Administration. The Government has certain rightsin certain embodiments of some of these invention(s).

COPYRIGHT NOTICE

This disclosure is protected under United States and InternationalCopyright Laws. ©2008-2009 The FeedRoom, Inc., All Rights Reserved. Aportion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure after formal publication by the USPTO, as itappears in the Patent and Trademark Office patent file or records, butotherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

A media player typically describes computer software used for playingback various audio and video multimedia files on both stand-alonecomputing devices and on computing devices connected to a network, suchas the Internet. Designers of these media players attempt to tailor theuser interface and functionality of their software applicationsaccording to various design preferences specified by their customers,who are either the hosts or users of these customized media players.

Today, many media players are designed to be embedded in various datadisplays, such as web pages, electronic programming guides, and othermobile software applications creating graphical compositions. The datadisplay platforms associated with these embedded media players caninclude specialized scripting which calls for a media player applicationresident on a host or client side, for dynamically embedding the playerin a particular data display. Adobe AIR™ platforms such as Flash™(previously Shockwave Flash, SWF) and Flash Lite™ are examples ofcommonly used platforms for embedding multimedia content such asstreaming video and audio into web pages. These Adobe platforms utilizethe ActionScript™ scripting language to create embedded content that iscapable of playing SWF (.swf) and Flash Video (.flv) data formats. Otherplatforms that facilitate embedding media applications in various webbased data displays include: Adobe Flex™, Microsoft Silverlight™, andSun Microsystems JavaFX™, and open source GNU/Linux platforms such asMoonlight™.

Whether a media player is designed as a stand-alone software applicationto be independently executed on a local computing device or whether amedia player is designed to be dynamically embedded in a web-based datadisplay, the goal of the software designer remains the same: to customtailor a media player to best meet a given customer's needs andpreferences. Unfortunately, at present, a media player customer whodesires specialized characteristics and functionality in their mediaplayer (either at the time of creation or as a subsequent modification),has to submit these custom specifications to a software designer forreprogramming, recompiling, and redistribution of a static media playerapplication. This redesign process is inefficient, time intensive, andunnecessarily expensive for most media player customers andapplications.

To remedy the above inefficiencies, it would be advantageous tofacilitate easy real-time creation and modification of custom designedmedia players.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is flowchart illustrating how the Designer, Asset Manager, andCompiler applications are in communication with the File System;

FIG. 2 illustrates a user with access to the Player Builder applicationlogging into the Player Builder by using a user name and/or passwordassociated with an approved customer account and the Player Builderretrieving a list of players from a File System;

FIG. 3 is a screenshot of the Player Builder application illustratingwhere a user is capable of selecting a “players” feature for viewing alisting of existing custom media players associated with playertemplates stored in the File System;

FIG. 4 illustrates one embodiment of the Player Listing template;

FIG. 5 illustrates one embodiment of the general design interface;

FIG. 6 illustrates one embodiment of the Size Design interface;

FIG. 7 illustrates one embodiment of the Style Design interface;

FIG. 8 illustrates one embodiment of the Content Design interface;

FIG. 9 illustrates one embodiment of the FreeForm Design interface;

FIG. 10 illustrates one embodiment of the Player Builder Applicationsinteracting with the Asset Manager and the Designer;

FIG. 11 illustrates one embodiment of the Player Builder in previewfunction;

FIG. 12 is a diagram illustrating one embodiment of the CompilerArchitecture;

FIG. 13 is a diagram illustrating one embodiment of the Embedded PlayerCompiler;

FIG. 14 is a diagram showing the Player File Components;

FIG. 15 is a screenshot illustrating a web based embedded playerapplication;

FIG. 16 is a screenshot showing one embodiment of the inventionutilizing Adobe Flash™ Player 9;

FIG. 17 is another view of the player;

FIG. 18 is yet another view of the player;

FIGS. 19-23 are additional views of embodiments of the player.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the present invention are directed to systems and methodsfor real-time creation and modification of specialized media players, tobe used as stand alone applications or as embedded data displayapplications. In various embodiments of the present invention theseapplications can include both host and client side applications. Exampleprogramming platforms that can be used to realize software applicationsassociated with the systems and methods of the present invention,include, but are not limited to, various Sun Microsystems JAVA™platforms and various Adobe AIR™ platforms. In an embodiment of thepresent invention, a system facilitating these objectives may includeone or more of at least the following components: a Player Builder, aDesigner, an Asset Manager, a File System, and a Compiler. In accordancewith an embodiment of the present invention, the Player Builderapplication is in communication with the Designer application, the AssetManager application, the Compiler application, and the File System.Further, each of the Designer, Asset Manager, and Compiler applicationsare in communication with the File System (See FIG. 1). Thefunctionality and significance of these components and theircommunications are discussed further, herein.

The Player Builder application provides an interface for a user toaccess and create various media player files using a personal computingdevice, such as desktop computer, a laptop computer, or any otherportable computing device. In certain embodiments of the presentinvention this computing device could be an isolated computing devicerunning the Player Builder application from a local directory. In otherembodiments, the computing device could be a networked device, runningthe Player Builder application from a networked directory location.

The Designer application preferably interfaces with the Player Builderapplication to permit a user to actively modify a selected player fileutilizing a variety of design interface tools that are available to auser in a design mode. The Asset Manager can be an application whichinterfaces with the Player Builder and the Designer applications toallow a user to associate certain preconfigured assets or media to aselect player during a design mode. The File System facilitates logicalstorage and retrieval of all data associated with the systems of thepresent invention, such as media files, parameter assets, assetcomponents, player files, etc. The Compiler can be an application thatimports and/or accesses a user created player data file (e.g., an XMLscript, various assets, and other associated data that may be generatedby or referenced with the Player Builder and/or Designer applications,and then compiles all of this combined data into one executable custommedia player application.

In accordance with an embodiment of the present invention, a user withaccess to the Player Builder application may log into the Player Builderby using a user name and/or password associated with an approvedcustomer account (See FIG. 2). Once in the Player Builder application, auser is capable of selecting a “players” feature for viewing a listingof existing custom media players associated with player templates storedin the File System (See FIG. 3). The media player listing displayed to auser further provides a user with the ability to redesign, remove,preview, and export a listed player. A template player listing (See FIG.4) provides a user with the ability to select and create a specializedtemplate media player with preconfigured assets and/or attributes thatmeet a user's design preferences. These template media players provide arelatively quick and easy way for a user to create a customized mediaplayer. In an embodiment of the present invention, selection of atemplate player invokes the Designer application so that a preconfiguredtemplate player can be dynamically modified with various design tools ina design mode.

A logged in user can also utilize the Player Builder application tocreate a new media player by selecting the “create new player” featurein the Player Builder interface. Selection of the “create new player”feature invokes the Designer application which can be run synchronouslywith the Player Builder application. In accordance with an embodiment ofthe present invention a user can create a new player without usingtemplates or previously designed media players as a starting point.These new players can be constructed from scratch, utilizing designtools and preconfigured player component blocks available to a user in adesign mode. These component block assets can be associated with a newplayer under design utilizing the Asset Manager application. In anembodiment of the present invention, the Asset Manger links a playeridentification to selected block component identifications in the FileSystem, for later retrieval by the Compiler application.

Various design interfaces associated with the Designer applicationinclude, but are not limited to, the following interfaces: General,Size, Style, Content, and Freeform (See FIGS. 5-9). The General designinterface (See FIG. 5) includes a graphical depiction of a media playerunder design (e.g., a player based on a previously designed media playerin the player listing (See FIG. 3), or based on a selected playertemplate (See FIG. 4)) and multiple user input areas where a user iscapable of entering a player name and a brief description of a playertype. In an embodiment of the present invention, the player descriptionis intended to designate a compatibility standard.

The Size design interface (See FIG. 6) allows a user to independentlysize various component block assets associated with a particular player.Component blocks can comprise various preconfigured script assets (e.g.,interactive command buttons, slide bars, dials, checkboxes, etc.) andvarious static parameter assets (e.g., color schemes, aspect ratios,video and sound specifications, etc.). An example embodiment of the Sizedesign interface includes multiple sizing handles associated withindividual component blocks, including: a player window block, a mediawindow block, and a player controls block. In accordance with thisembodiment, a user can select (e.g., by use of a single-click) and dragthe handles associated with a select component block to a desired sizeand position in a design window, to resize the select component block.The component block assets (e.g., buttons, slide bars, etc.) dynamicallyresize to correspond to the size and position associated with theresized component block. Alternatively, a user can manually enterheight, width, and positional values directly into a user input sizingwindow of the Size design interface, thereby dynamically resizing acomponent block and its asset components.

The Style design interface (See FIG. 7) allows a user to apply variousthemes to a media player under design and to various asset groupsassociated with component blocks of that media player. In someembodiments the themes apply to purely aesthetic characteristics and inother embodiments the themes can alter functionality associated withplayer component block assets. The Content design interface (See FIG. 8)allows a user to associate select multimedia files (e.g., video andaudio files) in a File System with a particular media player. In anembodiment, the Content design interface includes various user inputareas associated with a media ID, a media protocol, a host media server,a URL associated with a media location, and an auto play preference.Other input areas of the Content design interface can include variousbackground and video characteristics that a user can associate with amedia player.

With the Freeform design interface (See FIG. 9), a user can selectvarious parameters associated with a player window block, the mediawindow block, and the player controls block of a media player. In anembodiment of the present invention, these parameters include componentsizing parameters, background colors parameters, component fill colorparameters, and component opacity parameters. The Asset Managerassociates these asset parameters with block components stored in theFile System. After selecting various media player design preferences ineach of the General, Size, Style, Content, and Freeform designinterfaces, a user can save their associated media player designselections to the File System by selecting a save feature.

The Asset Manager application runs synchronously with the Player Builderand Designer applications (See FIG. 10). In some embodiments of thepresent invention, the Asset Manager creates a logical directory of dataassociated with a player file in the File System. This data can includestatic player parameter assets (e.g., color schemes, aspect ratios,video and sound specifications, etc.) and active player component assets(e.g., interactive command buttons, slide bars, dials, checkboxes,etc.). In an embodiment, a logical directory of player assetidentifications is linked to a corresponding player identification inthe File System. This asset to player linking facilitates dynamicretrieval of all data related to a player file at the time the Compilercompiles a specific user created player file.

The Player Builder application's player listing interface allows a userto view a listing of existing media players in the File System (See FIG.3). The media player listing further provides a user with the ability tomodify, preview, remove, and export a listed player. In an embodiment,when a user selects the modify option, the Player Builder invokes theDesigner application interface wherein a user can modify and associatevarious assets with the component blocks of a select player (See FIG.10). In a further embodiment, when a user selects the preview option,the Player Builder invokes the Compiler to compile a player file andassociated assets to create a preview related to the executable mediaplayer (See FIG. 11). In some embodiments the compiled preview player isdisplayed to a user as a scaled up image representation of what theplayer's user interface looks like and in other embodiments the compiledpreview is a full executable version of the listed media player. When auser selects the remove feature, a selected media player is removed fromthe listing and in some embodiments the File System as well. In anembodiment, when a user selects the export feature, a user is promptedto designate a local or remote directory location where to export anexecutable version of the listed media player.

When invoked, the Compiler application (See FIG. 12) imports and/oraccesses source code from a designated player file as well as static andactive player asset scripts corresponding to various attribute andcomponent block assets associated with the player file. In at least oneembodiment of the present invention some of these assets are stored in atemporary storage area of the File System. The player file compiles theplayer file and assets, creating an executable media player application.In an alternate embodiment, the Compiler is utilized to create anembedded web based media player application. In this embodiment, theCompiler (e.g., a JAVA™ based compiler) (See FIG. 13) imports and/oraccesses a player file (e.g., an XML player file) and generates a customscript wrapper and a web based platform compatible player file, used bya cross platform compiler (e.g., an Adobe Flash™ based compiler) to callplayer assets and script components and then compile the combinedinformation into a web based embedded player application (See FIG. 15).

In accordance with an embodiment of the present invention, an examplemedia player file includes both built in and externally input parameterasset files, a parameter cache, and various component assets (See FIG.14). After initialization of the media player all parameters are storedin a parameter cache area of the player. Component assets communicatewith each other indirectly (e.g., as class objects) when parameterchanges are detected in the player.

In 1998, Congress amended the Rehabilitation Act to require Federalagencies to make their electronic and information technology accessibleto people with disabilities. Inaccessible technology interferes with anindividual's ability to obtain and use information quickly and easily.Section 508 was enacted to eliminate barriers in information technology,to make available new opportunities for people with disabilities, and toencourage development of technologies that will help achieve thesegoals. The law applies to all Federal agencies when they develop,procure, maintain, or use electronic and information technology. UnderSection 508 (29 U.S.C. §794d), agencies must give disabled employees andmembers of the public access to information that is comparable to theaccess available to others.

Therefore, methods and systems for a disabled user compliant videoplayer for an end-to-end streaming web video solution affordingaccessibility for disabled users, including blind users and those withpartial or poor vision, colorblind users, deaf users and those limitedto only keyboard/voice input is also disclosed herein. The Video Playeradvantageously addresses the individual needs of all of these users,and, in some embodiments, is compliant with Section 508 of theRehabilitation Act, as amended in 1998, and in embodiments is compatibleLevel of “Triple-A*” for the W3C's Web Content Accessibility 1.0Guidelines.

The video player is preferably the Access Player developed by FeedRoombut may be any video player used for video over a data communicationlink, an Internet or an Intranet. The video player preferably isconfigured to play a plurality of formats of web video and multimedia,and is configured to be used by with persons who have disabilities. Theplayer is compliant with Flash as well as other video formats, and iscapable of displaying closed captions.

The player is fully functional with multiple file formats and operatingsystems, but is preferably compatible with FLV and DFXP files. Itprovides a means for disabled end-users to access and consume the videocontent, with, or without, the use of Assisted Technologies (AT). Theend-to-end solution encompasses placing an accessible link on theclient's site (home page, and/or library page) to an accessibleRepresentation of the stories in their Library (the ‘Access Map’). TheAccess Map will preferably be dynamically generated from a special Datafeed of the client's Library contents (the 508 Data feed), and willinclude links to an accessible RSS feeds page, an accessible Help page,as well as to a Access Player, capable of displaying synchronouscaptions for any video for which such associated metadata is available.

The player further includes player metric ping functionality; RSS pages;smart re-sizing of full-screen components, and/or tool tips for playercontrols. The player further includes the ability to pass in a parameter(into the Access Map) that would hide the left column of channelnavigation, essentially turning a multi-channel Access Library into asingle-channel Access Showcase.

The video player preferably contains, but is not limited to, three maincomponents: an Access Bar, an Access Map and an Access Player. An AccessBar is generally a persistent link that is placed at the top of aclient's Library page (it can also be placed elsewhere on the client'sweb site), and links to the client's Access Map. An Access Map ispreferably an Representation of the client's library that isadvantageously presented in a fully compliant manner, and providesnavigation between channels of client-specific content, and for eachvideo, provides a summary, thumbnail (which can include alt-text), andlinks to transcript files and the Access Player. A fully-accessible Helpmenu and RSS-links are available from the Access Map as well. An AccessPlayer is the video player itself and can allow for the presentation ofvideo with synchronous controls, can offer full-screen viewing mode, canoffer the ability to e-mail links to specific videos and can revealembed codes for including the Access Player on blogs or other web sites.All of this is advantageously accomplished while maintaining the highestlevel of accessibility to the broadest range of users.

In one embodiment, the digital player includes a feature that ensuresnon-text elements have a text equivalent, so that, for example, a blinduser could use screen-reading technology to inform him of what is on thescreen. This would include alt-text for every image, for example, theAccess Map may have a StoryTile image for every story and a ClientLogoimage in the header, at a minimum). The text used as alt-text for theseimages would differ from the text used for, e.g., the headline ofSubheadline (this story on American Reading Habits might have a Headline“Read Any Good Books Lately?” with a picture of a man on a park benchreading a book, and the alt-text would be “man reading book on parkbench”). Additionally, preferably every window could have a <title> tagthat is descriptive. Additionally, every story may have a link to aformatted transcript. The player may also include a Flash Player that ispreferably capable of displaying synchronous captions.

In one embodiment, the system and method will include versioning. Theproduct version can be adapted on a per user basis, allowing formultiple versions to be working at the same time and further includes aversion override mechanism which allows for the use of particularversions. Further still, the products persist over time while theversions may change. The product versioning may include but is notlimited to: product version will be implicit and controlled on per sitebasis; the version can be set explicitly by passing variables; theversion number may be multiple digits but in a preferred embodiment isthree digits (first designating major functional product revision,second for minor functional revision and/or third for bug fixes andminor cosmetic changes); the implicit version does not have to be thelatest version, but is user and/or developer specific; changing implicitversion may have a mini-release of the skin/property file, with the newversion that is quality assured; version number will preferably not bevisible in the URI; but preferably will be watermarked as an htmlcomment inside the pages for verification, audit and other purposes; allparts of the access product (map, FAQ, player, XML landing page etc)will preferably have to be on same version; moving one will requiremoving all to the same version; the actual directory structure willadvantageously be hidden using internal rewrite rules for linkpersistence and future compatibility; an/or prior versions may beeliminated.

One embodiment of the player may be configured to be capable ofsatisfying one or more of the following illustrative requirements:

(a) When software is designed to run on a The FeedRoom Access Help pagecontains system that has a keyboard, product functions shall informationon enabling full keyboard access in the be executable from a keyboardwhere the function MacOS. itself or the result of performing a functioncan be Using FeedRoom Access in conjunction discerned textually. withsome screen reading software preferably uses JavaScript to be enabled onthe web browser to attain full keyboard functionality. Instructions fordoing so are provided. (b) Applications shall not disrupt or disableFeedRoom Access meets these criteria. It activated features of otherproducts that are is compatible with the following operating systemidentified as accessibility features, where those and web browsercombinations: features are developed and documented according to WindowsVista industry standards. Applications also shall not Internet Explorer7 disrupt or disable activated features of any operating Firefox 2system that are identified as accessibility features Windows XP wherethe application programming interface for Internet Explorer 6 thoseaccessibility features has been documented by Internet Explorer 7 themanufacturer of the operating system and is Firefox 2 available to theproduct developer. Opera 9 Netscape 9 Windows 2000 Internet Explorer 6Firefox 2 Opera 9 Mac Panther (OSX 10.3) Safari 1 Firefox 2 Opera 8 MacTiger (OSX 10.4) Safari 2 Firefox 2 Opera 8 (c) A well-defined on-screenindication of FeedRoom Access supports keyboard the current focus shallbe provided that moves tabbing. FeedRoom Access also supports the well-among interactive interface elements as the input defined on-screenoutline that represents current focus changes. The focus shall beprogrammatically focus in the Access Player. exposed so that AssistiveTechnology can track focus and focus changes. (d) Sufficient informationabout a user FeedRoom Access supports this criterion. interface elementincluding the identity, operation All non-text elements have associatedtextual and state of the element shall be available to information.Assistive Technology. When an image represents a program element, theinformation conveyed by the image must also be available in text. (e)When bitmap images are used to FeedRoom Access meets these criteria.identify controls, status indicators, or other programmatic elements,the meaning assigned to those images shall be consistent throughout anapplication's performance. (f) Textual information shall be providedFeedRoom Access has support for this though operating system functionsfor displaying criterion. There is support for this in text fields (fortext. The minimum information that shall be made example, in certainstandard dialog boxes). available is text content, text input caretlocation, and text attributes. (g) Applications shall not override userFeedRoom Access meets these criteria. selected contrast and colorselections and other Applications recognize operating system settingsindividual display attributes. for user-selected contrast, color anddisplay attributes. (h) When animation is displayed, the FeedRoom Accesscan be configured to information shall be displayable in at least onenon- include any animations to display information to the animatedpresentation mode at the option of the user. user. (i) Color codingshall not be used as the FeedRoom Access supports this criterion. onlymeans of conveying information, indicating an Although the videoduration indicator and volume action, prompting a response, ordistinguishing a level indicator are presented using color as the visualelement. primary means of conveying information, the video progress isalso indicated by an on-screen time indicator, and the volume level isindicated by % of max volume, displayed below the volume indicator bar.(j) When a product permits a user to adjust FeedRoom Access can beconfigured to color and contrast settings, a variety of color permitcolor or contrast settings. selections capable of producing a range ofcontrast levels shall be provided. (k) Software shall not use flashingor FeedRoom Access can be configured to blinking text, objects, or otherelements having a include any flashing or blinking elements. flash orblink frequency greater than 2 Hz and lower than 55 Hz. (l) Whenelectronic forms are used, the FeedRoom Access meets these criteria.form shall allow people using Assistive Technology Regarding electronicforms full keyboard to access the information, field elements, andaccessibility is afforded for all supported OS/web functionalityrequired for completion and submission browser combinations. of theform, including all directions and cues. (a) A text equivalent for everynon-text FeedRoom Access includes functionality element shall beprovided (e.g., via “alt”, that makes it possible to display videos andrelated “longdesc”, or in element content). content within FeedRoomAccess that conform to this criterion. FeedRoom Access users areresponsible for ensuring that their video content's associated imagesconforms to this criterion. (b) Equivalent alternatives for any FeedRoomAccess includes functionality multimedia presentation shall besynchronized with that makes it possible to display videos within thethe presentation. FeedRoom Access Player that conform to this criterion.FeedRoom Access users are responsible for ensuring that their videosinclude associated caption files in DFXP format to ensue their videosconform to this criterion. (c) Web pages shall be designed so that allFeedRoom Access supports this criterion. information conveyed with coloris also available The video duration indicator and volume level withoutcolor, for example from context or markup. indicator are presented usingcolor as the primary means of conveying information, but the videoprogress is also indicated by an on-screen time indicator, and thevolume level is indicated by % of max volume, displayed below the volumeindicator bar. (d) Documents shall be organized so they FeedRoom Accesssupports this criterion. are readable without requiring an associatedstyle by using external stylesheets called via <link> tags, sheet. andall pages are organized so as to be readable without the stylesheets.(i) Frames shall be titled with text that FeedRoom Access supports thiscriterion facilitates frame identification and navigation by employingunique IDs for each <div>. (j) Pages shall be designed to avoid causingFeedRoom Access supports this criterion. the screen to flicker with afrequency greater than 2 Hz No elements of FeedRoom Access cause screenand lower than 55 Hz. flicker outside of the designated range. User's ofFeedRoom Access are responsible for the creation of the video contentdisplayed by FeedRoom Access. (k) A text-only page, with equivalent Someembodiments of FeedRoom Access information or functionality, shall beprovided to enable compliant presentation of FeedRoom make a web sitecomply with the provisions of this Library applications. FeedRoom Accesscan be part, when compliance cannot be accomplished in automaticallyupdated whenever the associated any other way. The content of thetext-only page FeedRoom Library is updated. shall be updated wheneverthe primary page changes. (l) When pages utilize scripting languagesFeedRoom Access supports this criterion to display content, or to createinterface elements, in that any instance of client-side scripting hasthe information provided by the script shall be associated <noscript>tags providing equivalent identified with functional text that can beread by functionality. Assistive Technology. (m) When a web pagerequires that an FeedRoom Access supports this criterion. applet,plug-in or other application be present on the The only plug-in that maybe used is Adobe Flash client system to interpret page content, the pagemust Player v9.0+. A link to obtain this plugin, or to provide a link toa plug-in or applet that complies update an older version, is providedin a manner with §1194.21(a) though (1). compliant with §1194.21(a)though (1). (n) When electronic forms are designed to FeedRoom Accesssupports this criterion, be completed on-line, the form shall allowpeople providing both access and instructions for users using AssistiveTechnology to access the requiring AT. information, field elements, andfunctionality required for completion and submission of the form,including all directions and cues. (o) A method shall be provided thatpermits FeedRoom Access supports this criterion, users to skiprepetitive navigation links. providing skip instructions where relevant.(c) All training and informational video FeedRoom Access displays andmultimedia productions which support the synchronous closed captions forall videos for agency's mission, regardless of format, that containwhich DFXP (Distribution Format Exchange speech or other audioinformation necessary for the Profile) caption files are available.FeedRoom can comprehension of the content, shall be open or convert manyformats of time-stamped transcripts closed captioned. into DFXP files,and can provide, as a premium service the creation of time-stampedtranscript, or raw transcription services to assist clients withcompliance. (d) All training and informational video FeedRoom Accessallows for links for and multimedia productions which support thecompliant transcript files for every video. agency's mission, regardlessof format, that contain FeedRoom can assist in the creation and/orhosting visual information necessary for the comprehension of suchfiles, if needed, to assist clients with of the content, shall be audiodescribed. compliance. (e) Display or presentation of alternate text Thedisplay of closed captions, for videos presentation or audiodescriptions shall be user- having associated DFXP files, is selectableby the selectable unless permanent. user in FeedRoom Access. (a) Atleast one mode of operation and FeedRoom Access supports the criterion,information retrieval that does not require user with few exceptions,allowing the use of screen vision shall be provided, or support forAssistive readers to access user interface information. Technology usedby people who are blind or Commonly-used Assistive Technology (AT) mayvisually impaired shall be provided. be used with FeedRoom Access. Usersof AT should contact their AT vendor to assess the compatibility oftheir product with various web browsers to learn how to adjust theirsettings to optimize interoperability. Known exceptions, including theuse of JAWS screen reader with the FireFox web browser, are noted in theFeedRoom Access Help FAQ. (b) At least one mode of operation andFeedRoom Access supports this criterion, information retrieval that doesnot require visual affording system large font settings, high contrastacuity greater than 20/70 shall be provided in audio settings, and otherdisplay settings used by visually and enlarged print output workingtogether or impaired customers, including a full-screen viewingindependently, or support for Assistive Technology mode. used by peoplewho are visually impaired shall be provided. (c) At least one mode ofoperation and FeedRoom Access supports this criterion. informationretrieval that does not require user FeedRoom Access provides the meansfor hearing shall be provided, or support for Assistive includingformatted transcripts for videos, as well Technology used by people whoare deaf or hard of as the display of synchronous, on-screen captions,hearing shall be provided in a manner that does not interfere with thepresentation of video. In all instances where FeedRoom Access providesan audio cue, a visual cue is provided as well. (d) Where audioinformation is important FeedRoom Access supports this criterion. forthe use of a product, at least one mode of Audio information is notimportant for the use of operation and information retrieval shall beFeedRoom Access, and text-based alternatives provided in an enhancedauditory fashion, or (transcripts and synchronous captions) are providedsupport for assistive hearing devices shall be for as described in§1194.31(c) herein. provided. (e) At least one mode of operation andFeedRoom Access supports this criterion. information retrieval that doesnot require user FeedRoom Access does not need speech interaction speechshall be provided, or support for Assistive for any functionality, butis compatible with Technology used by people with disabilities shallcommonly-used AT for navigation, control and be provided, inputting textinto forms. (f) At least one mode of operation and FeedRoom Accesssupports this criterion information retrieval that does not require finewith few exceptions. All functionality is possible motor control orsimultaneous actions and that is using only a keyboard, or alternate ATinput operable with limited reach and strength shall be devices. Oneknown exception is a security provided. limitation imposed by Adobe'sFlash plug-in to allow keyboard input when full-screen mode is invoked.

The preceding illustrative features may satisfy some accessibilityrequirements. Other possible embodiments may incorporate one or more ofthese features to satisfy alternate existing or future accessibilityrequirements.

While the preferred embodiment of the invention has been illustrated anddescribed, as noted above, many changes can be made without departingfrom the spirit and scope of the invention. Accordingly, the scope ofthe invention is not limited by the disclosure of the preferredembodiment.

1. A system for dynamically creating a custom media player applicationon a computing device, the personal computing device comprising: amemory for storing a player designer application and a compilerapplication; a processor; and a user interface, wherein a user can usethe player designer application to generate a markup language file andthen compile the markup language file into an executable media playerapplication using the compiler application.